1. Field of the Invention
The invention relates generally to the field of communications, and more specifically to a network configured for Voice over Internet Protocol (VoIP) and/or Facsimile over Internet Protocol (FoIP).
2. Background of the Related Art
Historically, most wired voice communications were carried over the Public Switched Telephone Network (PSTN), which relies on switches to establish a dedicated circuit between a source and a destination to carry an analog or digital voice signal. In the case of a digital voice signal, the digital data is essentially a constant stream of digital data. More recently, Voice over Internet Protocol (VoIP) was developed as a means for enabling speech communication using digital, packet-based, Internet Protocol (IP) networks such as the Internet. A principle advantage of IP is its efficient bandwidth utilization. VoIP may also be advantageous where it is beneficial to carry related voice and data communications over the same channel, to bypass tolls associated with the PSTN, to interface communications originating with Plain Old Telephone Service (POTS) with applications on the Internet, or for other reasons. As discussed in this specification, the problems and solutions related to VoIP may also apply to Facsimile over Internet Protocol (FoIP).
Throughout the description that follows there are references to analog calls over the PSTN. This phrase could refer to analog or digital data streams that carry telephone calls through the PSTN. This is distinguished from VoIP or FoIP format calls, which are formatted as digital data packets.
FIG. 1 is a schematic diagram of a representative architecture in the related art for VoIP communications between originating telephone 100 and destination telephone 145. In alternative embodiments, there may be multiple instances of each feature or component shown in FIG. 1. For example, there may be multiple gateways 125 controlled by a single controller 120. There may also be multiple controllers 120 and multiple PSTN's 115. Hardware and software components for the features shown in FIG. 1 are well-known. For example, controllers 120 and 160 may be Cisco SC2200 nodes, and gateways 125 and 135 may be Cisco AS5300 voice gateways.
To initiate a VoIP session, a user lifts a handset from the hook of originating telephone 100. A dial tone is returned to the originating telephone 100 via Private Branch Exchange (PBX) 110. The user dials a telephone number, which causes the PSTN 115 to switch the call to the originating gateway 125, and additionally communicates a destination for the call to the originating gateway 125. The gateway will determine which destination gateway a call should be sent to using a look-up table resident within the gateway 125, or it may consult the controller 120 for this information.
In related art systems, a general routing table is used to determine how a call should be routed. In practice, when a call request is received, the system consults the general routing table to obtain routing information that will be used to complete the call. The routing information could include the identity of one or more destination gateways that could be used to complete the call, and possibly preferred Internet Service Providers that should be used to complete the call. The originating gateway then tries to complete the call using the routing information from the general routing table.
In the related art systems, the same general routing table is used to route calls for all clients. However, in some instances, a particular client might want to try to route their calls through preferred destination gateways or preferred Internet Service Providers (ISPs). This could happen if the client has a financial interest in the company that owns and runs certain destination gateways and/or ISPs. One way to accommodate this client preference is to set up a separate routing table for each client that places calls through the system. The routing table for each client would list that client's preferred destination gateways and ISPs ahead of the other gateways and ISPs so that the system first attempts to complete calls using the client's preferred routes. However, creating and maintaining a full separate routing table for each client is time consuming, and it consumes system resources.
Once the originating gateway knows which destination gateway to use, the originating gateway then attempts to establish a call with the destination telephone 145 via the VoIP network 130, the destination gateway 135, signaling lines 155 and the PSTN 140. If the destination gateway and PSTN are capable of completing the call, the destination telephone 145 will ring. When a user at the destination telephone 145 lifts a handset and says “hello?” a first analog voice signal is transferred through the PSTN 140 to the destination gateway 135 via lines 155. The destination gateway 135 converts the first analog voice signal originating at the destination telephone 145 into packetized digital data (not shown) and appends a destination header to each data packet. The digital data packets may take different routes through the VoIP network 130 before arriving at the originating gateway 125. The originating gateway 125 assembles the packets in the correct order, converts the digital data to a second analog voice signal (which should be a “hello?” substantially similar to the first analog signal), and forwards the second analog voice signal to the originating telephone 100 via lines 155, PSTN 115 and PBX 110. A user at the originating telephone 100 can speak to a user at the destination telephone 145 in a similar manner. The call is terminated when the handset of either the originating telephone 100 or destination telephone 145 is placed on the hook of the respective telephone. In the operational example described above, the telephone 105 is not used.
In the related art, the controllers 120 and 160 may provide signaling control in the PSTN and a limited means of controlling a gateway at one end of the call. It will be appreciated by those skilled in the art that, in some configurations, all or part of the function of the controllers 120 and 160 as described above may be embedded into the gateways 125 and 135, respectively.
It is necessary to track each individual call that is placed to generate billing and payment information. The billing system must be capable of providing lists that identify, for each call, the calling party, the called party, the duration of the call, and the time of day the call was placed. The call information is then combined with rate information to determine how much should be charged for each call, and how much the system should pay to other service providers for completing calls to called parties
Prior art systems typically track information about each call to support the billing process. The tracked information is then complied at the end of each week or each day to determine who owes what for each call. This batch processing is time/resource consuming, and necessarily involves a delay between the time that calls are completed, and the time that bills are generated and sent. Also, because the call information is batch processed at the end of each week/day, there will be a delay before users even know what they owe for placed calls.